Complex server systems require administration to enable a variety of maintenance functions. For examples, different users in a Unix environment may wish to perform a wide variety of administrative actions, ranging from benign actions such as obtaining or reporting on statistical data pertaining to system performance or application program execution to highly sensitive actions such as making critical configuration changes to the system that can affect the service availability, as well as the way in which the hardware or software of the system functions.
In Unix, user access privilege for taking administrative actions generally mirror the Unix file system paradigm. That is Unix provides two categories of users: normal users and root users (also known as super-users). Normal users represent the majority of users and are given very little access privilege in order to prevent these users from taking actions that may be detrimental to system performance and functionality. On the other hand, root users are granted root privileges, which include the ability to perform highly critical operations such as changing the hardware and/or software configuration of the system. There is no middle ground.
In some systems, this all-or-nothing approach to user access privilege control has led to operational and security problems. For example, since normal users are prevented from performing many benign administrative actions such as obtaining statistical data pertaining to application program execution, they must request root users to perform these administrative actions on their behalf. If there are many normal users making these requests, root users may be overwhelmed with mundane administrative tasks. In some systems, the burden on root users and the concomitant bottleneck created by a limited number of root users servicing administrative requests from a much larger group of normal users have led some normal users to surreptitiously employ root access privilege to accomplish their work, sometimes with the tacit approval of some root users.
Furthermore, some root users are not as experienced as others in making critical changes to the system. In some cases, these users are given the root user status simply because they have limited administrative needs that cannot be accommodated by the normal user status. Yet, they have the same privileges under Unix as any other root user and can, once they are given the root user status, make potentially detrimental changes to the system.
To facilitate discussion, consider the Unix cluster arrangement of FIG. 1 in which the prior art user access privilege control paradigm is employed. In FIG. 1, there are shown two nodes: Node1 (102) and Node2 (104). Node1 (102) is shown having a cluster daemon 106, which is employed for inter-process communication between the cluster nodes. As is known, a daemon is a program executing in the background that executes commands when requested. Node2 (104) also has an analogous cluster daemon 108, which is employed to exchange data with cluster daemon 106 to facilitate communication between node1 (102) and node2 (104) and to execute certain operations on the nodes on behalf of the end users, if they have such operation privileges.
A software package A (110), representing an application, is shown executing on node1 (102), while a software package B (112), representing another application, is shown executing on node2 (104).
A plurality of remote systems SYS A, SYS B, and SYS C (122, 124, and 126 respectively) are shown. A plurality of users may be logged into each system, potentially with a given user logged on to multiple systems. These remote systems SYS A, SYS B, and SYS C access node1 (102) and node2 (104) through a hub 130 and a computer network 132. To control access by remote users from SYS A, SYS B, and SYS C to node1 and node2, a cmclnodelist is set up for each of the nodes. Accordingly, a cmclnodelist 140 is stored in a system disk 142 of node1 (102). A cmclnodelist 150 is stored in a system disk 152 of node2 (104).
If a user has an entry in cmclnodelist 140 (such as the entry “SYS A Jim,” the entry denotes that that user “Jim”, when logged onto SYS A, has access to cluster daemon (106) on node1 (102) to allow Jim to do the operations needed, without having to log on to node1 (102). In the example of FIG. 1, there is also an entry “Node 1 Jim.” Accordingly, when user “Jim” logs on to node1 (102), Jim can access cluster daemon 106 to perform operations as needed.
Note that the user access control paradigm of FIG. 1 requires that a cmclnodelist be created for each node of the cluster. Additionally, it is required that the cmclnodelists associated with the multiple nodes of a cluster be identical. This is because if they are not identical, user access may be inadvertently denied. For example, if the entry “node1 root” is not present in cmclnodelist 150, a remote user accessing node1 (102) may not be able to obtain status information from the cluster since the cluster daemon 108 associated with node2 (104) may not allow cluster daemon 106 associated with node1 (102) to obtain such information from node2 (104).
FIG. 2 shows, in a simplified manner, the steps involved in authorizing a user for an administrative action in accordance with the prior art user access control paradigm. Suppose a user employing a console coupled to node1 (102) wishes to halt the execution of the application shown as package A (110). In this case, the user logs into node1 (204) and issues a command to halt the execution of package A (206). In step 208, the system checks to ensure that the user has the authority to perform administrative commands, such as halting the execution of package A (206). This check of step 208 is designed to prevent malicious misuse, accidental error, or unauthorized operation by users who are otherwise listed in cmclnodelist entries. In the prior art, the user can only perform such potentially critical operations (such as the halting of the execution of package A) only if the user had logged in as root.
Note that the request is sent to the cluster daemon (such as cluster daemon 106) since cluster daemon 106 may need to send the request out onto the cluster to ascertain where package A is currently executed before package A can be halted. In the example of FIG. 1, package A happens to be executed on node1 (102). However, suppose node2 ((104) is responsible for coordinating execution of applications in the cluster. In this case, cluster daemon 106 of node1 (102) needs to communicate with cluster daemon 108 of node2 (104) in order to ascertain wherein package A is currently executed before package A can be halted.
If the user is not authorized (according to the check in step 208), the user's request to halt the execution of package A is denied (210). On the other hand, if the user is authorized, the operation is allowed to proceed (212).
With the availability of proxy servers, it has become more common to allow remote access to the cluster via a network. This provides users with greater convenience since users can employ their own personal computers to log into the cluster and to perform activities that traditionally have been available only to users using consoles directly connected to the cluster nodes.
However, as discussed above, remote access carries with it a high degree of security risks. If a remote system (such as a user on SYS A) is granted root privilege to perform certain administrative functions that a normal user is not permitted to do, that remote system now has full administrative privileges to perform potentially detrimental system reconfigurations. If a hacker can steal a password or gain access to the userID of a legitimate user authorized to log in as root, that hacker can, from a remote terminal, perform actions that can cause great harm to the cluster nodes. In this all-or-nothing authorization paradigm, granting administrative privileges to remote systems is highly risky.
Furthermore, it may be desirable at times to grant certain users enhanced privileges beyond those available to prior art non-root users but less than those privileges available to prior art root users. For example, in the prior art, a non-root users cannot perform even certain benign actions if the ability to perform these benign actions are beyond those provided to non-root users. In this situation, the system administrator is forced to either grant these users full root privileges, which increases the risk of such users performing accidental and/or malicious operations, or to deny these users any additional intermediate privileges. There is thus no middle ground.
Because of the rigid root/non-root classification of the prior art, users have resorted to unauthorized actions such as surreptitiously sharing or employing root or super-user passwords or access for the sake of convenience. While this approach is unapproved and the majority of these users will employ such access only to conveniently perform the aforementioned benign actions, the potential for accidental and/or malicious actions exist since the system is now open to those users.
The prior art user access control paradigm additionally imposes a heavy administrative burden on system administrators. When a new user is added or removed, the system administrator has to update all the authorization maps on the participating systems to grant/remove specific privileges associated with the user. Similarly, when a new system is added or removed, or moved from one cluster to another cluster, the system administrator has to update all of the authorization maps on the participating systems to reflect the changes.